1. Field of the Invention
The present invention relates to a computer system, and deals more particularly with a method, system, and computer program product for enabling the on-demand generation, packaging, and delivery of archive files (such as cabinet, or xe2x80x9c.cabxe2x80x9d, files and Java archive, or xe2x80x9c.jarxe2x80x9d, files).
2. Description of the Related Art
The Java programming language developed by Sun Microsystems, Inc. has gained wide acceptance for writing software for the Internet and World Wide Web. While compilers for most programming languages generate code for a particular operating environment, Java enables writing programs using a xe2x80x9cwrite once, run anywherexe2x80x9d paradigm. (xe2x80x9cJavaxe2x80x9d and xe2x80x9cWrite Once, Run Anywherexe2x80x9d are trademarks of Sun Microsystems, Inc.)
Java attains its portability through use of a specially-designed virtual machine (xe2x80x9cVMxe2x80x9d). This virtual machine is also referred to as a xe2x80x9cJava Virtual Machinexe2x80x9dor xe2x80x9cJVMxe2x80x9d. The virtual machine enables isolating the details of the underlying hardware from the compiler,used to compile the Java programming instructions. Those details are supplied by the implementation of the virtual machine, and include such things as whether little Endian or big Endian format is used for storing compiled instructions, and the length of an instruction once it is compiled. Because these machine-dependent details are not reflected in the compiled code, the code can be transported to a different environment (a different hardware machine, a different operating system, etc.), and executed in that environment without requiring the code to be changed or recompiledxe2x80x94hence the phrase xe2x80x9csite once, run anywherexe2x80x9d. The compiled code, referred to as Java xe2x80x9cbytecodexe2x80x9d, then runs on top of a JVM, where the JVM is tailored to that specific operating environment. As an example of this tailoring of the JVM, if the bytecode is created using little Endian format but is to run on a microprocessor expecting big Endian, then the JVM would be responsible for converting the instructions from the bytecode before passing them to the microprocessor.
Programs written in Java take two forms: applications and applets. Java applications are similar in operational characteristics to applications in other programming languages. A Java applet, on the other hand, is a special type of application which is intended to be dynamically downloaded at run-time to a user""s machine along with a Web page which invokes the code in the applet. Java applets thus provide a powerful model for dynamic network computing, where the applet software can be distributed within the traditional Web browsing paradigm with which many computer users are familiar. Java-enabled browsers make it very easy for a user to run a downloaded Java applet, where the user is required to do nothing more for execution than pointing the browser at the applet and clicking on a button. When initiated, the applet then runs within the Web browser that displays the Web page.
A number of files and classes may be required to run a particular Java applet, and the requirements for each applet may be different depending on the applet""s functionality. For example, one applet may display an image; another may calculate mortgage payments; still another may play a song; etc. To ensure that an applet has the required files and classes available on each client machine to which it is downloaded, those applet-specific files are typically packaged together with, and distributed with, the file containing the executable applet code. The file containing this package of information is referred to as an xe2x80x9carchivexe2x80x9d file.
Archive file contents are typically compressed, using a technique such as Lempel-Ziv compression, to reduce download time and thereby make the network distribution process more efficient. The file contents may also be digitally signed so that the receiver may verify that the contents were obtained from a trusted source. There are currently two popular archive file formats: (1) Java archive, or xe2x80x9cJARxe2x80x9d, format; and (2) cabinet, or xe2x80x9cCABxe2x80x9dformat. While the xe2x80x9cJARxe2x80x9d file format is used to distribute and archive Java applet files (to be processed, for example, by a Netscape Navigator(copyright) browser), the xe2x80x9cCABxe2x80x9d file format is used for distributing and archiving files for the Internet Explorer browser. An archive file created in one of these formats has the file suffix xe2x80x9c.jarxe2x80x9d or xe2x80x9c.cabxe2x80x9d, respectively. (xe2x80x9cNetscape Navigatorxe2x80x9d is a registered trademark of Netscape Communication Corporation.)
The files and classes which are to be packaged into a specific archive file are statically specified. Typically, the file and class names are entered into a file, where this file is then processed by a utility program. The utility program locates each specified file, retrieves a copy of that file, and includes the copy into the archive package which is being created. Once all the specified files are retrieved (and compressed and digitally signed, when applicable), the archive file is then stored. Upon receiving a request for a Web page which includes an applet reference, a server returns the requested Web page containing the applet reference; when the applet is then initiated from the rendered Web page, a subsequent request for the applet""s archive file is automatically sent back to the server by the rendering browser, and the server responds by returning the archive file.
This prior art approach is relatively inflexible, however, due to the manner in which the archive file content is statically specified and statically stored. Each file or class that is to be included in the archive must already exist. In some dynamic network computing scenarios, this may be not desirable or even possible. For example, consider an applet which allows a bank""s customer to review checking-account information. Electronic access to the checking-account information may require the applet to communicate with an application running on a different computer. A statically-generated archive file of the prior art cannot provide up-to-date communication-support code for the applet based upon the most current version of the server application.
According a need exists for a technique by which these shortcomings in the prior art can be overcome. This technique should provide the capability of dynamically retrieving and packaging the content of an archive file, at the time when the archived content is to be delivered to a requester, such that the packaged information is up-to-date. Preferably, the technique also enables specifying, with each content request, parameter values that may be used to dynamically generate the content. The present invention defines a novel approach to solving these problems, which will result in greater flexibility in specifying and constructing archive files.
An object of the present invention is to provide a technique whereby shortcomings in prior art archive file techniques can be overcome.
Still another object of the present invention is to provide a technique that will result in greater flexibility in specifying and constructing archive files.
Another object of the present invention is to provide a technique for dynamically retrieving and packaging the content of an archive file.
It is another object of the present invention to provide this technique such that the packaged information of an archive file is up-to-date at the time when the archived content is to be delivered to a requester.
It is yet another object of the present invention to provide a technique which enables specifying, with each content request, parameter values that may be used to dynamically generate (and customize) archive file content.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a method, system, and computer program product for dynamic archive file retrieval. This technique comprises: automatically sending a request for an archive file to a server over a network connection, responsive to encountering a reference to the archive file during execution of code on a client workstation, and wherein the request identifies a dynamic archive builder accessible from the server; dynamically building the requested archive file; returning the dynamically built archive file to the client workstation; and executing a program contained in the returned archive file at the client workstation. The reference may be a Uniform Resource Locator (URL) address of the dynamic archive builder.
The dynamic building may further comprise: generating or retrieving, by the dynamic archive builder, one or more files needed for the requested archive file, responsive to receiving the request; compiling selected ones of the generated or retrieved files; and packaging the compiled files and the generated or retrieved files which are not compiled, thereby creating the requested archive file.
The request may further specify one or more parameters, in which case the dynamic building may use these parameters to customize the requested archive file. The values of the parameters may be statically assigned, or they may be assigned dynamically, or a combination thereof.
The returned archive file may be a Java archive file, and the program may be a Java applet, a Java application, etc. Or, the returned archive file may be a cabinet file (or another type of archive file). When the returned archive file is a cabinet file, the program may be an applet, an application, etc.
The technique may further comprise: storing the dynamically built archive file in an archive cache; checking the archive cache, prior to operation of the dynamic building, for a previously cached version of the requested archive file; and bypassing operation of the dynamic building when the version is found. In this case, the returned archive file is the version found in the archive cache.
In one aspect, the technique may further comprise compressing the dynamically built archive file prior to the returning, in which case the returned archive file is the compressed file. In another aspect, the technique may further comprise digitally signing the dynamically built archive file prior to the returning, in which case the returned archive file is the digitally signed file.